In data communication environments, many different vendors provide a number of products for specific services. A machine, an application operating on a machine or a file system residing on a machine (“component”) developed by one vendor might have difficulty communicating with a component developed by another. Domain-specific protocols have been developed to partially deal with this difficulty by enabling components to communicate with each other using a common language. But since new components are constantly being introduced into and taken out of an environment it has been difficult to develop a system or protocol that is not domain-specific yet is sufficiently robust to enable unknown, arbitrary components to enter the environment and communicate with each other without having to be programmed explicitly in advance.
For instance, if a new type of printer is connected to a computer, the computer would need to be programmed explicitly to be able to communicate with the new printer by installing a driver specific to that printer. In a system, such as Jini™, developed by Sun Microsystems of Palo Alto, Calif., and described in “A collection of Jini™ Technology Helper Utilities and Services Specifications,” Palo Alto, Calif., Sun Microsystems, Inc., pp. 1-214, 2000; and “Jini™ Technology Core Platform Specification,” Palo Alto, Calif., Sun Microsystems, Inc., pp. 1-126, 2000, all of which are hereby incorporated by reference in their entirety, which uses domain-specific interfaces, in order for a personal digital assistant (“PDA”) to communicate with a printer, for example, the PDA must contain a priori knowledge of the semantics of the printer's programmatic interfaces. Moreover, a component that knows how to print, such as a printer, still may not know how to access a file system operating on the PDA device, for example, until it is programmed explicitly to communicate with the file system programmatic interfaces of the PDA.
Other difficulties may arise once communication is established among components using domain-specific protocols. Some components, such as computers, typically employ various mechanisms for providing feedback or allowing a user to control some aspect of the component's behavior during data transfers and other operations. Examples include a computer displaying a printer control panel for changing printer settings, a dialog box for selecting a particular file to print, or displaying a progress bar window when copying a file from a network file server to the computer. Unfortunately, these mechanisms are either inherent to the computer itself or are part of a pre-installed application that supports the user's task. In either case, the specific instructions for these mechanisms must be known in advance by the component, such as the computer, in the same manner described above with respect to the domain-specific protocols, which limits the ability for applications to interact in an ad hoc manner with components they are not explicitly programmed to use.